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REMARKS 

Applicant appreciates the time taken by the Examiner to review Applicant's present 
application. This application has been carefully reviewed in light of the Official Action mailed 
October 24, 2008 ("Office Action"). Claim 49 is amended herein and includes definitions 
provided in the specification as originally filed. No new matter is introduced. No claim is newly 
added. Claims 49, 51-60 and 65-73 remain pending. Applicant respectfully requests 
reconsideration and favorable action in this case. 



Rejections under 35 U.S.C. § 103 

Claims 49, 51-52, 56-59, 65, 68-70 and 73 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Patent Application Publication No. 2003/0105770 ("MacLeod") in 
view of U.S. Patent Application Publication No. 2003/0208387 ("VanDusen"), further in view of 
newly cited U.S. Patent Application Publication No. 2002/0049626 ("Mathias"). The rejection is 
traversed. Arguments submitted in the previous Replies pertaining to MacLeod remain 
pertinent to the rejection and therefore are incorporated herein by reference. Claims 65 and 70 
contain similar language as claim 49. Accordingly, traversal of the rejection will be collectively 
addressed as it pertains to claim 49. 

Claim 49, as previously presented, recites: 

A method for integrating legacy data into a content management system, 
comprising: 

analyzing a set of legacy data residing in a legacy repository external to 
said content management system; 

generating a set of content types to represent the set of legacy data 
based on the analysis of the legacy data, wherein one of the 
content types comprises a policy annotation, the policy annotation 
comprising management information including a workflow 
corresponding to the content type; 

saving the set of content types in a memory; 

generating a set of content type objects corresponding to the set of 
content types; 

generating a set of content instance objects from the content type 
objects; 

associating each of the set of legacy data with at ieast one of the content 
instance objects, wherein at least one of the content instance 
objects is associated with two or more datum of the set of legacy 
data, each of the datum residing in a distinct data storage; and 
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managing the set of legacy data using the content instance objects, 
wherein the two or more datum are managed as a single entity 
using the at least one content instance object. 

Thus, embodiments as claimed in claim 49 are directed to a method for integrating 
legacy data into a content management system. The method may include analyzing a set of 
legacy data residing in a legacy repository external to the content management system, 
generating a set of content types to represent the set of legacy data based on the analysis of 
the legacy data, saving the set of content types in a memory, generating a set of content type 
objects corresponding to the set of content types, associating each of the set of legacy data 
with at least one of the content instance objects and managing the set of legacy data using the 
content instance objects. One of the content types may include a policy annotation having 
management information including a workflow corresponding to the content type. At least one 
of the content instance objects may be associated with two or more datum of the set of legacy 
data. The legacy data, which resides at a data repository external to the content management 
system, can then be managed using the content instance objects, which are instantiated at the 
content management system. In this way, instead of having to import all of the legacy data into 
a repository, a user can merely create content types based on an existing model and then use 
an attach method to allow the new system to take over management of the existing data. 

MacLeod is generally concerned with a directory schema with object classes that have 
flexible attributes such that attributes of an object can be extended independent of 
modifications. To this end, MacLeod provides a flexible content class, wherein the flexible 
content class includes a flexible attribute. See MacLeod, Figure 4. The flexible attribute content 
class can be assigned any number of values. See MacLeod, paragraph [0054]. Thus, the 
application of MacLeod can assign any type of information to attributes of objects instantiated 
from the same object class, and this ability is accomplished without needing to modify the 
directory schema to create new structural object classes or attributes. See MacLeod, paragraph 
[0058], [0062]. 

VanDeusen is generally concerned with a method of doing business and a security 
instrument. As submitted in the Reply to the Office Action mailed on February 6, 2008, 
VanDusen appears to teach content management of content items in a website through the use 
of metadata. See VanDusen, paragraph 0078. VanDusen teaches that when new content 
items are added to a system, users apply category metadata to the content items in the system 
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and this metadata appears to be used to develop profiles for users which may be used to 
personalize content and product information shown to the users. See VanDusen, paragraph 
0080. 

Mathias is generally concerned with a method and system for interfacing clients with 
relationship management (RM) accounts and for permissioning marketing. A CRM system may 
collect data from external databases and third party information providers. See Mathias, 
paragraph [0062]. Mathias teaches that legacy systems within large enterprises typically are 
mutually-incompatible and are not configured to effectively communicate with each other. See 
Mathias, paragraph [0070]. 

In the rejection, the Examiner states that MacLeod teaches a method for integrating 
data into a content management system, including analyzing a set of data and generating a set 
of content types to represent the set of data based on the analysis of the data. Applicant 
respectfully disagrees and maintains that MacLeod is not concerned with legacy systems. As 
submitted in the Reply to the Office Action mailed on October 15, 2007, MacLeod explicitly 
describes that a directory schema is a collection of base content classes and associations and 
that directory schemas are typically very carefully designed (and hence cannot to be readily 
altered) to provide content classes to meet present and future requirements of a directory. See 
MacLeod, paragraphs 2-3. As such, MacLeod's description of a content class defining the 
purpose or content of an item by containing as its elements a list of properties appropriate for 
that purpose, or the teaching of a flexible attribute does not address the problems of integrating 
legacy data. Thus, MacLeod does not appear concerned with analyzing legacy systems or 
otherwise integrating legacy data into a content management system as recited in claim 49. 

Applicant respectfully submits that the teachings of VanDeusen fail to remedy the 
deficiencies of MacLeod. In the rejection, the Examiner states that VanDeusen discloses 
analyzing a set of data and generating a set of content types and teaches that a key component 
of a broad content management solution is the strategic use of metadata (site categories). 
However, VanDeusen is concerned with the situation in which business users add new content 
items to a system (e.g., a website) and teaches applying site category metadata information to 
the items so that it becomes easier for end users to find information of interest to them. As an 
example, an end user of a portal can request all items about a given sports team, or all articles 
about a given league written by a given author. Because every piece of content that an end 
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user views is tracked, it becomes easier to create a specific profile of that user. See 
VanDeusen, paragraph [0080]). However, VanDeusen's method of tracking what content is 
viewed by a user of a website and applying site category metadata does not read on analyzing 
data and generating a set of content types, as recited in claim 49. 

Similarly, Applicant respectfully submits that the teachings of Mathias fail to remedy the 
deficiencies of MacLeod and VanDeusen. In the rejection, the Examiner states that Mathias 
teaches legacy data residing in a legacy repository external to the content management 
system, and that Mathias' teachings would have allowed MacLeod and VanDeusen to provide 
an effective communication, integration, organization of data collection from a variety of 
sources such as legacy databases. Mathias describes an external database coupled to a data 
interchange, in which the external database contains data that is appropriate for inclusion into a 
data repository. Thus, a client relationship manager (CRM) system collects data from 
relationship and product managers via user terminals, as well as external databases and third 
party information providers. See Mathias, paragraphs [0062], [0070]. However, Mathias 
describes a data interchange that is responsible for transferring and translating data from one 
part of a CRM system to another. The data interchange may have a data stream handler, 
which converts data into a stream of messages, a cross-referencing system, which allocates an 
identifier to every client of an enterprise and maintains a mapping between local identifiers and 
corresponding global client identifiers, and a network interface. See Mathias, paragraphs [0064- 
0068]. The use of a data interchange to communicate between different portions of a data 
management system represents a situation in which embodiments as claimed in claim 49 can 
advantageously avoid. 

Although itself has no force of law, the M.P.E.P. restates the following law: The rationale 
to support a conclusion that the claim would have been obvious is that all the claimed elements 
were known in the prior art and one skilled in the art could have combined the elements as 
claimed by known methods with no change in their respective functions, and the combination 
yielded nothing more than predictable results to one of ordinary skill in the art. KSR, 550 U.S. at 

, 82 USPQ2d at 1395; Sakraida v. AG Pro, inc., 425 U.S. 273, 282, 189 USPQ 449, 453 

(1976); Anderson's-Black Rock, Inc. v. Pavement Salvage Co., 396 U.S. 57, 62-63, 163 USPQ 
673, 675 (1969); Great Atlantic & P. Tea Co. v. Supermarket Equipment Corp., 340 U.S. 147, 
152, 87 USPQ 303, 306 (1950). M [l]t can be important to identify a reason that would have 
prompted a person of ordinary skill in the relevant field to combine the elements in the way the 
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claimed new invention does." KSR, 550 U.S. at , 82 USPQ2d at 1396. If any of these 

findings cannot be made, then this rationale cannot be used to support a conclusion that the 
claim would have been obvious to one of ordinary skill in the art. See M.P.E.P. 2143. 

As submitted above and previously, Macleod, VanDusen, and Mathias disclose uniquely 
different inventions that solve different problems, none of which pertains to helping business 
users to manage their legacy data without changing either the structure or the location of the 
data. As an example, paragraph 22 of Macleod discloses a definition of a schema. Paragraph 
22 of Macleod does not whatsoever disclose "analyzing a set of data and generating a set of 
content types to represent the set of data based on the analysis of the data," as the Examiner 
stated on page 3 of the Office Action. VanDusen, in a completely different context, discloses 
using metadata to tag or mark content items (paragraph 78) and how a business manager 
might define a set of policies for controlling the management of product promotions 
(paragraphs 133 and 276). The rejection simply fails to identify any reason whatsoever that 
would have prompted a person of ordinary skill in the relevant field to combine a schema 
definition as disclosed by Macleod and a method of tagging content items to be associated with 
workflow templates for the purpose of controlling the management of product promotions as 
disclosed by VanDusen. Furthermore, in this example, the resulting combination of Macleod 
and VanDusen fails to arrive at a method comprising "analyzing a set of legacy data residing in 
a legacy repository external to said content management system" and "generating a set of 
content types to represent the set of legacy data based on the analysis of the legacy data, 
wherein one of the content types comprises a policy annotation, the policy annotation 
comprising management information including a workflow corresponding to the content type," 
as set forth in claim 49. 

What is more, the Examiner stated on page 8 of the Office Action that the newly cited 
Mathias may allow Macleod and VanDusen to "provide an effective communication, integration, 
organization of data collection from [a] variety of sources such as legacy databases." 
Assuming that Macleod, VanDusen, and Mathias were combinable, the Examiner's statement 
actually supports Applicant's position that the combination of Macleod, VanDusen, and Mathias 
fails to read on embodiments as claimed in claim 49. As submitted above, embodiments as 
claimed in claim 49 eliminate the need to collect/migrate the legacy data from an external data 
repository. A user can merely create content types based on an existing model and then use 
an attach method to allow the new system to take over management of the existing data. This 
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method obviates any need to manipulate the data itself, or to move the data to an additional 
repository. Accordingly, the legacy data residing in the external data repository can be 
managed by a new content management system without changing the structure or the location 
of the data. Since the combination of Macleod, VanDusen, and Mathias would have involved 
collecting data from a variety of sources, eliminating the need of data collection would not have 
been a predictable result to one of ordinary skill in the art at the time the invention was made. 
At least for this reason, this rationale cannot be used to support a conclusion that embodiments 
as claimed would have been obvious to one of ordinary skill in the art at the time of the 



As a good faith effort to expedite the prosecution of the present application, claim 49 is 
amended herein without prejudice or disclaimer. As amended, claim 49 recites: 



A method for integrating legacy data into a content 
management system, comprising: 

analyzing a set of legacy data residing in a legacy 
repository external to said content management system; 

generating a set of content types to represent the set of 
legacy data in the content management system based on the 
analysis of the legacy data, wherein one of the content types 
comprises a policy annotation, the policy annotation comprising 
management information including a workflow corresponding to 
the content type; 

saving the set of content types in a memory; 

generating a set of content type objects corresponding to 
the set of content types, wherein a content type object is an 
instantiation of a content type embodied in the content 
management system; 

generating a set of content instance objects from the 
content type objects, wherein each content instance object is an 
instantiation of a content instance and is associated with a content 
type object or a content type; 

associating each of the set of legacy data with at least one 
of the content instance objects, wherein at least one of the 
content instance objects is associated with two or more datum of 
the set of legacy data, each of the datum residing in a distinct 
data storage; and 

managing the set of legacy data residing in the legacy 
repository using the content instance objects of the content 
management system, wherein the two or more datum are 
managed as a single entity using the at least one content instance 
object. 



invention. 
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It is respectfully submitted claim 49 recites subject matter not reached by the 
combination of Macleod, VanDusen, and Mathias under 35 U.S.C. § 103(a) and therefore 
should be allowed. For similar reasons, claims 51-52, 56-59, 65, 68-70 and 73 are also 
submitted to be allowable over the combination of Macleod, VanDusen, and Mathias under 35 
U.S.C. § 103(a). Accordingly, withdrawal of this rejection is respectfully requested. 

Claims 53-55, 60, 66-67 and 71-72 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over MacLeod in view of VanDusen and further in view of Mathias as applied to 
claims 49, 51-52, 56-59, 65, 68-70 and 73 above, further in view of U.S. Patent Application 
Publication No. 2004/0187100 ("Thiruvillamalai"). The rejection is traversed. Arguments 
submitted in the previous Replies pertaining to Thiruvillamalai remain pertinent and thus are 
incorporated herein by reference. 

Thiruvillamalai is generally concerned with data store for arbitrary data types with safe 
type storage and retrieval, and describes a type construct that at compile time is instantiated to 
generate a unique type of data store that can hold listed types of arbitrarily typed data objects 
and methods to access the data store in a manner that allows any object of a listed type to be 
put in the data store. See Thiruvillamalai, paragraph [0007]. 

In the rejection, the Examiner states that Thiruvillamalai discloses generating values for 
the set of keys for each of the content instance objects. Applicant respectfully disagrees and 
submits that Thiruvillamalai describes a Put method that maintains a type index in association 
with each element and a Get method that validates that the type of object that was requested in 
the call to the Get method matches the object type that was stored in the Put method, and the 
Get method further returns the element data if there is a type match. However, Thiruvillamalai 
does not appear to generate anything other than a run-time exception in the event the Get is 
unable to validate that the type of object that was requested in the call to the Get method 
matches the object type that was stored in the Put method. See Thiruvillamalai, paragraph 
[0007]. Furthermore, one of ordinary skill in the art, at the time the invention was made, had no 
apparent reason to combine Thiruvillamalai with three other distinct inventions, namely, 
Macleod, VanDusen, and Mathias, Even if Macleod, VanDusen, Mathias, and Thiruvillamalai 
were properly combinable, the resulting combination still fails to read on embodiments as set 
forth in claims 53-55, 60, 66-67 and 71-72 for at least the reasons submitted above with 
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reference to claims 49, 51-52, 56-59, 65, 68-70 and 73. Accordingly, withdrawal of this 
rejection is respectfully requested. 
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CONCLUSION 



Applicant respectfully requests that the Examiner withdraw his rejections of the claims, 
Applicant has now made an earnest attempt to place this case in condition for allowance. Other 
than as explicitly set forth above, this reply does not include an acquiescence to statements, 
assertions, assumptions, conclusions, or any combination thereof in the Office Action. For the 
foregoing reasons and for other reasons clearly apparent, Applicant respectfully requests full 
allowance of claims 49, 51-60 and 65-73. The Examiner is invited to telephone the 
undersigned at the number listed below for discussing an Examiner's Amendment or any 
suggested actions for accelerating prosecution and moving the present application to 
allowance. 

The Director of the U.S. Patent and Trademark Office is hereby authorized to charge 
any fees or credit any overpayments to Deposit Account No. 50-3183 of Sprinkle IP Law Group. 



Respectfully submitted 



Sprinkle IP Law Group 

Attorneys for Applicant 




Katharina Wang Schuster 
Reg. No. 50,000 



Date: January ^ , 2009 



1301 W. 25 in Street, Suite 408 
Austin, TX 78705 
Tel. (512) 637-9220 
Fax. (512) 371-9088 



